(Foreword: The following development post is written by the project lead of our studio, Mr. Mai Nguyen Binh Hung (a.k.a Delta Kangara). He has discovered new techniques to generate the terrain in easier ways, as well as opened new potentials for our game, Battle Splash)
The concept is simple: A big map, with a lots of stuffs! Well, technically, YES, it's that simple, let aside the map design, stories line, assets, art style or whatever. However, "THAT SIMPLE" comes with a great price:performance and resource management. Imaging a huge world with a lot of trees, rocks, houses, and many more "little things" like barrels, fences, or even some interior item like cup or spoon (Skyrim, yes?), and all of them fits into a single, resource limited computer. I'm not talking about some players or developers' machine with 16~32GB RAM, core i7, GTX 9XX and so on, I'm talking about much lower rig, something likecore i3~i5, Intel HD, 2~4GB of RAM, etc... Of course, some of you may think that: nah, that's just a common office rig, not suitable for gaming or something. Yet, if the game can "run", or can "barely run" on those machine, I believe it can perform well on high-end machine (I've been expected it to be 40~60FPS with maximum settings on medium rig) as well as its efficient in term of quality scaling.
To deal with the concept, several approaches have been listed out based on my knowledge and my research. The very first approaches is very simple: do a single experiment that uses only a single, huge terrain object and see what is the cost of a terrain. I've been tweaking around Unity and try to make the biggest map as possible. So far, the countryside map is the biggest playable map that I've created, but as for the scope of the experiment, I've created a single terrain with the size is 100 times bigger than the Countryside map. To make it clear, the tallest character of Battle Splash is Quadra with the height of 1.8 meters, while the biggest map's diameter that I've tried is around 7692.3 times larger than her height. Therefore, I believed that the actual map size is around 169 square kilometers (theoretically), with 200k trees from 3 different types. And here is some actual rendering with that big size of the map:
Here are some statistics for Nerd:
- Resolution 1920x920 (Unity GUI prevented full HD in editor)
- Average FPS: 65 (capped). Actual FPS: ~250FPS
- Tree types: 3. Trees in terrain: 200k
- Terrain and trees only, wind effect included.
In other words, I'm very surprised with the result. The draw distance was about 277 meters, and even when I tried to increase the draw distance and camera far clip plane to around 10 kilometers, average FPS still exceed 60 compared to the previous test. Unity terrain system did it job in simulating such a huge area. And as for the memory, the map take up to more than 100MB. Of course, this test doesn't mean it is possible to make a 169 km2 map out of the box with Unity, in terms of both technical and content development. However, it doesn't deny the fact either, that it is POSSIBLE to make such map if suitable methods are applied. Let's dig in and find out how!
The test showed that it is possible to achieve 60 FPS in rendering such terrain. However, the maps only contains trees and a single terrain object, and no grass or terrain foliage, so the FPS can dramaticallyincrease. In addition, there are only 3 types of tree, which were highly optimized and used in the Countryside map, thus there should be no problem rendering thousand of them (if there was, perhaps I had to re-optimize those trees again).
The thing that I did not mention before is the workflow to produce a map. Well, things often start from map concepts, then design, then sculpting the terrains (or importing height map), then placing assets (both procedural and traditional), etc... For this test only, all I've done are placing trees automatically, setting up splat map and then try to sculpt the terrain. There are some problems to be considered. First of all is the visual representation of the map itself. The map was too big, and navigation was really such a pain. It's hard to find the right place to sculpt and also there is no pivot that helps identify the correct height or shape of the chosen areas. The way to solve this problem is kinda simple (which I will discuss in the next part), yet the other problems seems to be way more serious than this one.
The picture above represents the Navigation map for a much smaller map (59 square kilometers, less trees than the 169 km2 one) and it took me almost 20 minutes to finish all the calculations. The size of this navigation mesh is about 70MB, compared to 6MB of Countryside map. The process used up almost 1.5GB of RAM, and you can imagine what would happen if I baked 169km2 map instead of this one. And there is not much assets just yet, so if there is any problem with navigation, then re-baking it might be a greater pain. Oh, about Occlusion Bake, you asked? Nah, my computer is NOT gonna last.
And for the final result, well....
The above picture represent the final image of the map, which was applied several image effects. To be honest, I'm quite satisfied with the result. Unity does a very good job with the terrain system in terms of rendering. But it's just the graphics, let alone physics, game logic and ton of additional assets. There will be plenty of problems such as: memory management, navigation (yes, huge map might lead to performance spike), Occlusion Culling, etc... Still, our workflow for such huge map is unclear at the moment, so I'll continue to dig deeper into it in order to make sure the balance between performance and quality.
